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99 Abstract 

100 This Recommendation specifies four types of SHA-3-derived function: cSHAKE, KMAC, 

101 TupleHash, and ParallelHash, each defined for a 128- and 256-bit security level. cSHAKE is a 

102 customizable variant of the SHAKE function, as defined in FIPS 202. KMAC (for Keccak 

103 Message Authentication Code) is a variable-length message authentication code algorithm based 

104 on Keccak; it can also be used as a pseudorandom function. TupleHash is a variable-length hash 

105 function designed to hash tuples of input strings without trivial collisions. ParallelHash is a 

106 variable-length hash function that can hash very long messages in parallel. 
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1 Introduction 


Federal Information Processing Standard (FIPS) 202, SHA-3 Standard: Permutation-Based Hash 
and Extendable-Output Functions [1], defines four fixed-length hash functions (SHA3-224, 
SFIA3-256, SFIA3-384, and SFIA3-512), and two extendable Output Functions (XOFs), 
SFIAKE128 and SHAKE256. These SFIAKE functions are a new kind of cryptographic 
primitive; unlike earlier hash functions, they are named for their expected security level. 

FIPS 202 also supports a flexible scheme for domain separation between different functions 
derived from Keccak —the algorithm [2] that the SFIA-3 Standard is based on. Domain 
separation ensures that different named functions (such as SHA3-512 and SHAKE128) will be 
unrelated. cSHAKE—the customizable version of SHAKE—extends this scheme to allow users 
to customize their use of the function, as described below. 

Customization is analogous to strong typing in a programming language; such customization 
makes it extremely unlikely that computing one function with two different customization strings 
will yield the same answer. Thus, two cSHAKE computations with different customization 
strings (for example, a key fingerprint and an email signature) are unrelated: knowing one of 
these results will give an attacker no information about the other. 

This Recommendation defines two cSHAKE variants, cSHAKE128 and cSHAKE256, in Sec. 3, 
based on the Keccak[c] sponge function [3] defined in FIPS 202. It then defines three additional 
SHA-3-derived functions, in Secs. 4 through 6, that provide new functionality not directly 
available from the more basic functions. They are: 

• KMAC 128 and KMAC256, providing pseudorandom functions (PRFs) and keyed hash 
functions with variable-length outputs; 

• TupleHashl28 and TupleHash256, providing functions that hash tuples of input strings 
correctly and unambiguously 1 ; and 

• ParallelHash 128 and ParallelHash256, providing efficient hash functions to hash long 
messages more quickly by taking advantage of parallelism in the processors. 

All four functions defined in this Recommendation—cSHAKE, KMAC, TupleHash, and 
ParallelHash—have these properties in common: 

• They are all derived from the functions specified in FIPS 202. 

• All the functions except cSHAKE are defined in terms of cSHAKE. 

• All support user-defined customization strings. 

• All support variable-length outputs of any bit length, with the additional property that any 
change in the requested output length completely changes the function. Even with 


1 TupleHash processes a tuple of one or more input strings, and incorporates the contents of all the strings, the 
number of strings, and the specific content of each string in the calculation of the resulting hash value. Thus, any 
change (such as moving bytes from one input string to an adjacent one, or removing an empty string from the 
input tuple) is extremely likely to lead to a different result. 


1 
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205 identical inputs otherwise, any of these functions, when called with different requested 

206 output lengths, will, in general, yield unrelated outputs. 

207 • All support two security levels: 128 and 256 bits. 

208 These functions are detailed in the specific sections below. In addition, a method is specified in 

209 Appendix B to facilitate using these functions to produce output that is almost uniformly 

210 distributed on the integers {0, 1, 2,..., R- 1}. 

211 
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2 Glossary 


In this document, bits are indicated in the Courier New font. Bytes are typically written as two- 
digit hexadecimal numbers from the ASCII characters 0 through 9 and A through F, preceded by 
the prefix “Ox”. In binary representation, bytes are written with the low-order bit first, while in 
hexadecimal representation, bytes are written with the high-order digit first. E.g., 0x01 = 
10000000 and 0x80 = 00000001 . These bit-ordering conventions follow the conventions 
established in Sec. B.l of FIPS 202. Character strings appear in this document in double-quotes. 
Character strings are interpreted as bit strings whose length is a multiple of 8 bits, consisting of a 
0 bit, followed by the 7-bit ASCII representation of each successive character. 

2.1 Terms and Acronyms 


Bit 

CMAC 

cSHAKE 


A binary digit: 0 or 1. 

Cipher-based Message Authentication Code. 
The customizable SFIAKE function. 


Domain Separation 

eXtendable-Output 
Function (XOF) 

FIPS 

Hash Function 

HMAC 

Keccak 

KMAC 

MAC 

NIST 

PRF 


For a function, a partitioning of the inputs to different application 
domains so that no input is assigned to more than one domain. 

A function on bit strings in which the output can be extended to 
any desired length. 

Federal Information Processing Standard. 

A function on bit strings in which the length of the output is 
fixed. The output often serves as a condensed representation of 
the input. 

Keyed-Hash Message Authentication Code. 

The family of all sponge functions with a Keccak-/ permutation 
as the underlying function and multi-rate padding as the padding 
rule. Keccak was originally specified in [2], and standardized in 
FIPS 202. 

Keccak Message Authentication Code. 

Message Authentication Code. 

National Institute of Standards and Technology. 

See Pseudorandom Function. 


Pseudorandom Function A function that can be used to generate output from a random 

seed such that the output is computationally indistinguishable 
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(PRF) 

Rate 

SHA-3 


from truly random output. 

In the sponge construction, the number of input bits processed 
per invocation of the underlying function. 

Secure Hash Algorithm-3. 


Sponge Construction The method originally specified in [3] for defining a function 

from the following: 1) an underlying function on bit strings of a 
fixed length, 2) a padding rule, and 3) a rate. Both the input and 
the output of the resulting function are bit strings that can be 
arbitrarily long. 

Sponge Function A function that is defined according to the sponge construction, 

possibly specialized to a fixed output length. 

String A sequence of bits. 


XOF 


See eXtendable-Output Function. 


222 2.2 Basic Operations 


\x] For a real number x, [x| is the least integer that is not strictly less than 

x. For example, [3.2] =4, [-3.2] =-3, and [6] = 6. 

CF For a positive integer s, 0 ,v is the string that consists of s consecutive 0 

bits. 


enc8<7) 


For an integer / ranging from 0 to 255, encs(z) is the byte encoding of i, 
with bit 0 being the low-order bit of the byte. 


len(A') 


For a bit string X, lcn(X) is the length of X in bits. 


mod(a, b ) 


The modulo operation. mod(a, b) returns the remainder after division of 
a by b. 


X\\ Y 


For strings X and Y,X || Y is the concatenation of X and Y. For example, 

11001 II 010 = 11001010. 


223 2.3 Other Internal Functions 

224 This section describes the string encoding, padding and substring functions used in the definition 

225 of the SHA-3-derived functions. 

226 2.3.1 Integer to Byte String Encoding 

227 Two internal functions, left_encode and right_encode, are defined to encode integers as byte 
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strings. Both functions can encode integers up to an extremely large maximum, 2 2040 -l. 

left_encode(x) encodes the integer x as a byte string in a way that can be unambiguously parsed 
from the beginning of the string by inserting the length of the byte string before the byte string 
representation of x. 

right_cncodc(x) encodes the integer x as a byte string in a way that can be unambiguously parsed 
from the end of the string by inserting the length of the byte string after the byte string 
representation of x. 

Using the function encxi ) to encode the individual bytes, these two functions are defined as 
follows: 

right_encode(x): 

Validity Conditions: 0 <x < 2 2040 

1. Let n be the smallest integer for which 2 8n > x. 

2. Let xi, X2,...,x„ be the base-256 encoding ofx satisfying: 

x = X 2 X|V,) x,, for i = 1 ton. 

3. Let Oi = cncslxi), for i = 1 to n. 

4. Let On +i = encx(//). 

5. Return O = 0\ || Oi || ... || On || 0«+i. 

leftencode(x): 

Validity Conditions: 0 <x < 2 2040 

1. Let n be the smallest integer for which 2 8n > x. 

2. Let xi, X 2 , ..., Xn be the base-256 encoding of x satisfying: 

x = X 2 8 (,m) x;, for i = 1 to n. 

3. Let Oi = encs(x/), for i = 1 to n. 

4. Let Oo= enc8(n). 

5. Return O = Oo\\ Oi \\ ... || 0„-i || On. 

2.3.2 String Encoding 

The encode string function is used to encode bit strings in a way that may be parsed 
unambiguously from the beginning of the string, S. The function is defined as follows: 

encode_string(5): 

Validity Conditions: 0 < len(S) < 2 2040 
1. Return I e ft_encode( I en(.S')) || S. 

Note that if the bit string S is not byte-oriented (i.e., len(S') is not a multiple of 8), the bit string 
returned from encode string^ is also not byte-oriented. However, if lcn(.S') is a multiple of 8, 
then the length of the output of cncodc string(.S') will also be a multiple of 8. 
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2.3.3 Padding 

The bytepad(X, vv) function pads an input string X with zeros until it is a byte string whose length 
in bytes is a multiple of vv. In general, bytepad is intended to be used on encoded strings—the 
byte string bytepad(encode_string(5), vv) can be parsed unambiguously from its beginning, 
whereas bytepad does not provide unambiguous padding for all input strings. 

The definition of bytepad() is as follows: 

bytepad(X, w): 

Validity Conditions: w> 0 

1. z = leftencode(w) || X. 

2. while len(z) mod 8*0: 

z = z || 0 

3. while (len(z)/8) mod vv * 0: 

z = z || 00000000 

4. return z. 

2.3.4 Substrings 

Let parameters a and b be non-negative integers that denote a specific position in a bit string X. 
Informally, the substring^ a, b ) function returns a substring from the bit string X containing the 
values at positions a, a+ 1, ..., b~ 1, inclusive. More precisely, the substring function operates as 
defined below. Note that all bit positions in the input and output strings are indexed from zero. 
Thus, the first bit in a string is in position 0, and the last bit in an /7-bit string is in position n~ 1. 

substring^, a, b ): 

1. If a > b or a > len(X): 

return the empty string. 

2. Else if b < len(2Q: 

return the bits of X from position a to position b~ 1, inclusive. 

3. Else: 

return the bits of X from position a to position len(30-l, inclusive. 
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cSHAKE 


298 3.1 Overview 


299 The two variants of cSHAKE—cSHAKE 128 and cSHAKE256—are defined in terms of the 

300 SHAKE and Keccak[c] functions specified in FIPS 202. cSHAKE128 provides a 128-bit 

301 security level, while cSHAKE256 provides a 256-bit security level. 

302 3.2 Parameters 


303 Both cSHAKE functions take four parameters: 


304 

305 

306 

307 

308 

309 


• A is the main input bit string. It may be of any length, including zero. 

• L is an integer representing the requested output length, in bits. 

• S is a customization bit string. The user selects this string to define a variant of the 
function. When no customization is desired, S is set to the empty string 2 . 

• A is a function-name bit string, used by NIST to define functions based on cSHAKE. 
When no function other than cSHAKE is desired, A is set to the empty string. 


310 An implementation of cSHAKE may reasonably support only input strings and output lengths 

311 that are whole bytes; if so, a fractional-byte input string or a request for an output length that is 

312 not a multiple of 8 would result in an error. 

313 When S and A are both empty strings, cSHAKE(A, L, S, A) is equivalent to SHAKE as defined in 

314 FIPS 202. Thus, 

315 cSHAKE128(X, L, "") = SHAKE128(X, L) and 

316 cSHAKE256(X, L, "") = SHAKE256(X, L). 

317 cSHAKE is designed so that for any two instances: 

318 cSHAKE(Xl, Zl, 51, Al) and 

319 cSHAKE(Al, L 1, 52, A2), 

320 unless 51 = S2 and A1 = A2, the two instances produce unrelated outputs. Note that this includes 

321 the case where 51 and A1 are empty strings. That is, cSHAKE with any customization is domain- 

322 separated from the ordinary SHAKE function specified in FIPS 202. 


2 In computing languages that support default values for parameters, a natural way to implement this function would 
set the default values for S and N to empty strings. 
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3.3 Definition 

cSHAKE is defined in terms of SHAKE or Keccak[c], as follows: it either returns the result of a 
call to SHAKE (if S and N are both empty strings), or returns the result of a call to Keccak(c) 
with a padded encoding of S and N concatenated to the input string X. 

cSHAKE128(A, L, S, N): 

Validity Conditions: len(S)< 2 2040 and len(N)< 2 21140 

1. If 5= "" and A= 

return SHAKE 128(A, L); 

2. Else: 

return KECCAK[256](bytepad(encode_string( 1 S) || cncodc_string(/V), 168) | A | 0 0, L). 

cSHAKE256(A, L, S, N): 

Validity Conditions: len(S)< 2 2040 and len(N)< 2 2040 

1. If 5'= "" and A= 

return SHAKE256(X, L); 

2. Else: 

return KECCAK[512](bytepad(encode_string( 1 S) || cncodc_string(/V), 136) || X\\ 0 0, L). 

Note that the numbers 168 and 136 are rates (in bytes) of the Keccak[ 256] and Keccak[ 512] 
sponge functions, respectively; and the characters 00 in the Courier New font in these 
definitions specify two zero bits. 

3.4 Using the Customization String 

The cSHAKE function includes an input string ( S) to allow users to customize their use of the 
function. For example, someone using cSHAKE128 to compute a key fingerprint (the hash value 
for a public key) might use: 

cSHAKE \2S(public_key, 256, "key fingerprint", ""), 

where "key fingerprint" is a customization string S. 

Later, the same user might decide to customize a different cSHAKE computation for signing an 
email: 


cSHAKE 1 2S(email_contents, 256, "email signature", ""), 
where "email signature" is the customization string S. 

The customization string is intended to avoid a collision between these two cSHAKE values—it 
will never be possible for an attacker to somehow use one computation (the email signature) to 
get the result of the other computation (the key fingerprint) if different values of S are used. 


The customization string may be of any length less than 2 2040 ; however, implementations may 
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360 restrict the length of S that they will accept. 

361 3.5 Using the Function Name Input 

362 The cSHAKE function also includes an input string that may be used to provide a function name 

363 (TV). This is intended for use by NIST in defining SHA-3-derived functions, and should only be 

364 set to values defined by NIST. This parameter provides a level of domain separation by function 

365 name. Users of cSHAKE should not make up their own names—that kind of customization is the 

366 purpose of the customization string S. Nonstandard values of N could cause interoperability 

367 problems with future NIST-defined functions. 

368 
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E 



4.1 Overview 

The Keccak Message Authentication Code (KMAC) algorithm is a PRF and keyed hash 
function based on Keccak. It provides variable-length output, and unlike SHAKE and cSHAKE, 
altering the requested output length generates a new, unrelated output. KMAC has two variants, 
KMAC 128 and KMAC256, built from cSHAKE 128 and cSHAKE256, respectively. The two 
variants differ somewhat in their technical security properties. Nonetheless, for most 
applications, both variants can support any security level up to 256 bits of security, provided that 
a long enough key is used, as discussed in Sec. 8.4.1 below. 

4.2 Parameters 

Both KMAC functions take the following parameters: 

• A is a key bit string of any length, including zero. 

• A is the main input bit string. It may be of any length, including zero. 

• L is an integer representing the requested output length 3 in bits. 

• S' is an optional customization bit string of any length, including zero. If no customization 
is desired, S is set to the empty string. 

4.3 Definition 

KMAC concatenates a padded version of the key K with the input X and an encoding of the 
requested output length L. The result is then passed to cSHAKE, along with the requested output 
length L, the optional customization string S, and the name N ="KMAC" = 01001011 
01001101 01000001 01000011. 


KMAC128(A, X, L, S): 

Validity Conditions: len(K) < 2 2040 and 0 <L < 2 2040 and len(S) < 2 2040 

1. newX= bytepad(encode_string(A), 168) || X\\ rightencode(Z). 

2. return cSHAKE128(»ewA, L, S, “KMAC”). 

KMAC256(A, X, L, S): 

Validity Conditions: len(K) <2 2040 and 0 <L < 2 2040 and len(S) < 2 2040 

1. newX= bytepad(encode_string(A), 136) || X\\ right cncode(L). 

2. return cSHAKE256(«ewX, L, S, “KMAC”). 


3 Note that there is a limit of 2 2040 -l bits of output from this function unless the function is used as a XOF, as 
discussed in Sec. 4.3.1. 
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402 Note that the numbers 168 and 136 are rates (in bytes) of the Keccak[256] and Keccak[512] 

403 sponge functions, respectively. 

404 4.3.1 KMAC with Arbitrary-Length Output 

405 Some applications of KMAC may not know the number of output bits they will need until after 

406 the outputs begin to be produced. For these applications, KMAC can also be used as a XOF (i.e., 

407 the output can be extended to any desired length) which mimics the behavior of cSHAKE. 

408 When used as a XOF, KMAC is computed by setting the encoded output length L to 0. 

409 Conceptually, when called with an encoded length of zero, KMAC produces an infinite-length 

410 output string, and the caller simply uses as many bits of the output string as are needed. 

411 
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5.1 Overview 

TupleHash is a SHA-3-derived hash function with variable-length output that is designed to 
simply and correctly hash a tuple of input strings, any or all of which may be empty strings. Such 
a tuple may consist of any number of strings, including zero, and is represented as a sequence of 
strings or variables in parentheses like (a, b, c,...z ) in this document. 

TupleHash is designed to provide a generic, misuse-resistant way to combine a sequence of 
strings for hashing such that, for example, a TupleHash computed on the tuple ("abc" ,"d") will 
produce a different hash value than a TupleHash computed on the tuple ("ab","cd"), even though 
all the remaining input parameters are kept the same, and the two resulting concatenated strings, 
without string encoding, are identical. 

TupleHash supports two security levels: 128 bits and 256 bits. Changing any input to the 
function, including the requested output length, will almost certainly change the final output. 

5.2 Parameters 

TupleHash takes the following parameters: 

• Xis a tuple of zero or more bit strings, any or all of which may be an empty string. 

• L is an integer representing the requested output length, in bits. 

• .S' is an optional customization bit string of any length, including zero. If no customization 
is desired, S is set to the empty string. 

5.3 Definition 

TupleHash encodes the sequence of input strings in an unambiguous way, then encodes the 
requested output length at the end of the string, and passes the result into cSHAKE, along with 
the function name (A) of “TupleHash” = 01010100 01110101 01110000 01101100 
01100101 01001000 01100001 01110011 01101000. 

If X is a tuple of n bit strings, let X\f\ be the zth bit string, numbering from 0. The TupleHash 
functions are defined in pseudocode as follows: 

TupleHashl28(X, L, S): 

Validity Conditions: 0 <L < 2 2040 and len(S) < 2 2040 

1. z = "". 

2. n = the number of input strings in the tuple X. 

3. for i = 1 to n: 

z=z || cncode_string(A[i]). 

4. newX= z || rightcncodc(L). 

5. return cSHAKE \2S(newX, L, S, “TupleHash”). 
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TupIeHash256(X, L, S): 

Validity Conditions: 0 <L < 2 2040 and len(S) < 2 2040 

1. z = " M . 

2. n = the number of input strings in the tuple X. 

3. for i = 1 to n: 

z = z || cncode_string(X[i]). 

4. newX= z || rightencode(Z). 

5. return cSHAKE256(/?evvX, L, S, “TupleHash”). 

5.3.1 TupleHash with Arbitrary-Length Output 

Some applications of TupleHash may not know the number of output bits they will need until 
after the outputs begin to be produced. For these applications, TupleHash can also be used as a 
XOF (i.e., the output can be extended to any desired length) which mimics the behavior of 
cSHAKE. 

When used as a XOF, TupleHash is computed by setting the encoded output length L to 0. 
Conceptually, when called with an encoded length of zero, TupleHash produces an infinite- 
length output string, and the caller simply uses as many bits of the output string as are needed. 
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6 ParallelHash 4 


6.1 Overview 

The purpose of ParallelHash is to support the efficient hashing of very long strings, by taking 
advantage of the parallelism available in modern processors. ParallelHash supports the 128- and 
256-bit security levels, and also provides variable-length output. Changing any input parameter 
to ParallelHash, even the requested output length, will result in unrelated output. Like the other 
functions defined in this document, ParallelHash also supports user-selected customization 
strings. 

6.2 Parameters 

ParallelHash takes the following parameters: 

• Xis the main input bit string. It may be of any length, including zero. 

• B is the block size in bytes for parallel hashing. It may be any integer > 0. 

• L is an integer representing the requested output length, in bits. 

• S is an optional customization bit string of any length, including zero. If no customization 
is desired, S is set to the empty string. 

6.3 Definition 

ParallelHash divides the input bit string X into a sequence of non-overlapping blocks, each of 
length B bytes, and then computes the hash value for each block separately. Finally, these hash 
values are combined and hashed to generate the final hash value of the function. The name field 
N of cSHAKE is set to "ParallelHash" = 01010000 01100001 01110010 01100001 
01101100 01101100 01100101 01101100 01001000 01100001 01110011 
01101000. 

The ParallelHash functions are defined in pseudocode as follows: 

ParalleIHashl28(X, B, L, S ): 

Validity Conditions: 0 < B < 2 2040 and [ len(X)/B ] < 2 2040 and 
0 <L < 2 2040 and len(S) < 2 2040 

1. n= \ (len(X)/8) / B ]. 

2. z = lcft_cncode(7>). 

3. i = 0. 

4. for i "= 0 to n~\ : 

z = z || cSHAKE 128(substring(X, i*B* 8, (z+l)*8*8), 256, ""). 


4 A generic parallel hash mode for other NIST-approved hash functions may be developed in the future. The 
function here (i.e., ParallelHash) is specifically based on cSHAKE, and thus, on KECCAK. 
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5. z = z || rightencode(n) || right cncodc(L). 

6. newX=z. 

7. return cSHAKE \28(newX, L, S, “ParallelHash”). 

ParallelHash256(X, B, L, S ): 

Validity Conditions: 0 < B < 2 2040 and [ len(X)/B ] < 2 2040 and 
0 < L < 2 2040 and len(S) < 2 2040 

1. n= \ (len(X)/8) / B ]. 

2. z = left_encode(5). 

3. i = 0. 

4. for / = 0 to /7— 1: 

z = z II cSHAKE256(substring(X, i*B* 8, (i+\)*B* 8), 512, 

5. z = z || rightencode(fl) || rightcncodc(L). 

6. newX-z. 

7. return c S H AKE256(« e wX, L, S, “ParallelHash”). 

6.3.1 ParallelHash with Arbitrary-Length Output 

Some applications of ParallelHash may not know the number of output bits they will need until 
after the outputs begin to be produced. For these applications, ParallelHash can also be used as a 
XOF (i.e., the output can be extended to any desired length) which mimics the behavior of 
cSHAKE. 

When used as a XOF, ParallelHash is computed by setting the encoded output length L to 0. 
Conceptually, when called with an encoded length of zero, ParallelHash produces an infinite- 
length output string, and the caller simply uses as many bits of the output string as are needed. 
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7.1 Precomputation 

cSHAKE is defined to fill one entire call'' to the underlying Keccak-/ function [1] with the byte 
string resulting from encoding and padding the customization string S and the name string N (see 
Sec. 3.3). However, an implementation can precompute the result of processing this padded 
block with cSHAKE, and thus, will suffer no performance penalty when reusing the same 
choices of S and N in multiple cSHAKE executions. Since TupleHash, and ParallelHash are 
defined in terms of cSHAKE, this same precomputation is available to implementations of those 
functions, as well. 

KMAC can precompute the result of hashing S and N, and the result of hashing the key K. Thus, 
KMAC 128 using a fixed, precomputed customization string and key will process an input string 
as efficiently as SHAKE 128. 

7.2 Limited Implementations 

The cSHAKE, KMAC, TupleHash, and ParallelHash functions are defined to accept a wide 
range of possible inputs (including unreasonably long inputs, and inputs including fractional 
bytes), and to produce a wide range of possible output lengths. However, it is acceptable for a 
specific implementation to limit the possible inputs that it will process, and the allowed output 
lengths that it will produce. 

For example, it is acceptable to limit an implementation of any of these functions to producing 
no more than 65536 bytes of output, or to producing only whole bytes of output, or to accepting 
only byte strings (never fractional bytes) as inputs. Additionally, implementations intended for 
only a specific, limited use may further restrict the sets of inputs they will process. For example, 
an implementation of TupleHash256 used only to process a 6-tuple of strings, and always using a 
customization string of "address tuple", would be acceptable. 

If it is possible for an implementation of one of these functions to be given a set of inputs that it 
cannot process, then the implementation shall signal an error condition and refuse to produce an 
output. 

7.3 Exploiting Parallelism in ParallelHash 

Specific implementations of ParallelHash are pennitted to restrict their implementation to a small 
subset of the allowed values. For example, it would be acceptable for a particular implementation 
to only allow a single value of B if it were only expected to interoperate with another 
implementation that similarly restricted B to that same value. 


5 Each call to the underlying KECCAK-/ function processes r bits, where r is the rate parameter. For CSF1AKE128, r 
= 1344 bits; for cSHAKE256, r = 1088 bits. 
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554 ParallelHash can be implemented in a straightforward and reasonably efficient way even when 

555 only sequential processing is available. However, a much faster implementation is possible when 

556 each of the individual blocks of the message can be handled in parallel. The choice of block size 

557 B can have a huge impact on the efficiency of ParallelHash in this case. ParallelHash is designed 

558 so that any machine that can apply parallel processing can, in principle, benefit from that parallel 

559 processing; a machine that can hash four blocks in parallel and a machine that can hash 32 

560 blocks in parallel can each benefit from all the parallel processing ability that is available. 

561 
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8 Security Considerations 


8.1 Security Properties for Name and Customization String 

8.1.1 Equivalent Security to SHAKE for Any Legal S and N 

For a given choice of S and N, cSHAKE 128(76, L, S, N) has exactly the same security properties 
as SHAKE 128(A, L); and cSHAKE256(A, L, S, N) has exactly the same security properties as 
SHAKE256(X, L). There are no "weak" values for S or N. 

8.1.2 Different S and N Give Unrelated Functions 

Suppose (si, n 1) and (s2, n 2) are two customization and name strings pairs, and either .s i A s2, or 
n 1 n2. Furthermore, suppose xland x2 are input strings, and q 1 and q2 are lengths of the 

requested output. Then, cSHAKE(xl, q I, ,sI, nl) and cSHAKE(x2, q2, s2, n2) are unrelated 
functions. That means: 

• Knowledge of a set of outputs of cSHAKE(X, L, si, nl) gives no information about any 
output of cSHAKE (X, L, s2, nl). 

• The probability that cSFIAKE(xl, q I, ,sl, nl) and cSHAKE(x2, q I, s2, nl) have the same 
value is 2~ qX . 

Because KMAC, TupleHash, and ParallelHash are derived from cSHAKE, they inherit these 
properties. Specifically: 

• Each of these functions is unrelated to any of the other functions. There is no relationship 
between KMAC (for any set of inputs) and TupleHash (for any set of inputs). 

• For any of these functions, using a different customization string gives an unrelated function. 
Thus, if si ^ s2, Pa rail cl Hash (A, B, L, .si) and ParallelHash(A, B, L, si) are unrelated 
functions: knowing the output of one function gives no information about the output of the 
other. 

8.2 Claimed Security Level 

cSHAKE, KMAC, TupleHash, and ParallelHash are all defined for two claimed security levels: 
128 bits and 256 bits. 

cSHAKE128, KMAC128, TupleHashl28, and ParallelHash 128 each provides a security level of 
128 bits. This means that, for a given output length L, there is no generic attack on one of these 
functions requiring less than 2 128 work that does not also exist for any hash function with the 
same output length. Similarly, cSHAKE256, KMAC256, TupleHash256, and ParallelHash256 
each provides a security level of 256 bits. 

Note that a claimed security level of 128 bits is a lower bound on its security—under some 
circumstances, an algorithm like KMAC 128, claiming 128 bits of security, may provide higher 
than 128-bit security in practice. 
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602 8.3 Collisions and Preimages 

603 All these functions support variable output lengths. The difficulty of an attacker finding a 

604 collision or preimage for any of these functions depends on both the claimed security level and 

605 the output length. 

606 A function like cSHAKE 128, with a claimed security level of 128 bits, may be vulnerable to a 

607 collision or preimage attack with 2 128 work regardless of its output length—a longer output does 

608 not, in general, improve its security against these attacks. However, a shorter output makes the 

609 function more vulnerable to these attacks. With an output of L bits, a collision attack will require 

610 about 2 m work, and a preimage attack will require about 2 L work. 

611 8.4 Guidance for Using KMAC Securely 

612 For maximum flexibility and usefulness, the KMAC functions are defined for arbitrary-sized 

613 output lengths and key lengths. However, not all such output and key lengths are secure. 

614 8.4.1 KMAC Key Length 

615 The input key length is the parameter that is most straightforwardly translated into a security 

616 level. Given a small number of known (MAC, plaintext) pairs, an attacker requires at most 2 len ® 

617 operations to find the key K. 

618 Applications of this Recommendation shall not select an input key, K, whose length is less than 

619 their required security level. Guidance for cryptographic algorithm and key-size selection is 

620 available in [4], 

621 8.4.2 KMAC Output Length 

622 The output length is another important security parameter for KMAC—it determines the 

623 probability that an online guessing attack will succeed in forging a MAC tag. In particular, an 

624 attacker will need to submit, on average, 2 L invalid (message, MAC) pairs for each successful 

625 forgery. Since L only affects online attacks, a system that uses KMAC for message 

626 authentication can mitigate attacks that exploit a short L by limiting the total number of invalid 

627 (message, MAC) pairs that can be submitted for verification under a given key. 

628 When used as a MAC, applications of this Recommendation shall not select an output length L 

629 that is less than 32 bits, and shall only select an output length less than 64 bits after a careful risk 

630 analysis is perfonned. 

631 To illustrate the security properties of KMAC for given parameter settings, Table 1 lists other 

632 approved MAC algorithms, CMAC[5] and HMAC[6], along with equivalent settings for KMAC. 

633 Note that equivalent settings do not result in the same output. 

634 Table 1: Equivalent security settings for KMAC and previously standardized MAC algorithms 


Existing MAC Algorithm 

KMAC Equivalent 

CMAC (K, text ) 

KMAC 128 (K, text, 128, S) 
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HMAC-SHA256 (K, text) 

KMAC256 (K, text, 256, S) 

HMAC-SHA512 (K, text) 

KMAC256 (K, text, 512, 5) 
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Appendix A—KMAC, TupleHash, and ParallelHash in Terms of Keccak[c] 


FIPS 202 specifies the Keccak[c] function, on which the SHA-3 and SHAKE functions are 
built. KMAC, TupleHash, and ParallelHash are defined in terms of cSHAKE, as specified in 
Sec. 3. In this appendix, KMAC, TupleHash, and ParallelHash are defined directly in terms of 
Keccak[c]. These definitions are exactly equivalent to the definitions made in terms of 
cSHAKE in Secs. 4, 5, and 6. 

KMAC128(ff, X, L, S): 

Validity Conditions: len(K) < 2 2040 and 0 <L < 2 2040 and len(S) < 2 2040 

1. newX= bytepad(encode_string(A), 168) || X\\ rightencode(Z). 

2. T= bytepad(encode_string(5) || encode_string(“KMAC”), 168). 

3. return Keccak[256](T || newX\\ 00 , L). 

KMAC256 (K,X,L,S): 

Validity Conditions: len(K) < 2 2040 and 0 <L < 2 2040 and len(S) < 2 2040 

1. newX= bytepad(cncodc_string(/Q, 136) || X\\ right cncodc(L). 

2. T = bytepad(encode_string(5) || encode_string(“KMAC”), 136). 

3. return Keccak[512](T || newX || 00 , L). 

TupleHashl28(A, L, S ): 

Validity Conditions: 0 <L < 2 2040 and len(S) < 2 2040 

1. z = "". 

2. n = the number of input strings in the tuple X. 

3. for i = 1 to n: 

z = z || encode_string(A[i]). 

4. newX= z || rightencode(Z). 

5. T = bytepad(encode_string(,S) || encode_string(“TupleHash”), 168). 

6. return KECCAK[256](r|| newX\\ 00 , L). 

TupIeHash256(A, L, S ): 

Validity Conditions: 0 <L < 2 2040 and len(S) < 2 2040 

1. z = " M . 

2. n = the number of input strings in the tuple X. 

3. for i = 1 to n: 

z = z j| encode_string(A[i]). 

4. newX= z || right_encode(Z). 

5. T= bytepad(encode_string( 1 S) || encode_string(“TupleHash”), 136). 

6. return Keccak[512](T || newX || 00, L). 

ParallelHashl28(A, B, L, S ): 

Validity Conditions: 0 < B < 2 2040 and [ len(X)/B ] < 2 2040 and 
0 < L < 2 2040 and len(S) < 2 2040 
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1. n=\ (len(A)/8) / B]. 

2. z = left_encode(i?). 

3. for / = 0 to n~ 1: 

z = z || Keccak[ 256]( substring^ i*B* 8, (7+l)*5*8) || 1111, 256). 

4. z = z || rightencode(n) || right cncodc(L). 

5. newX=z. 

6. T = bytepad(encode_string(5) || encode_string(“ParallelHash”), 168). 

7. return KECCAK[256](r || newX || 00 , L). 

ParallelHash256(AT, B, L, S ): 

Validity Conditions: 0 < B < 2 2040 and [ len(X)/B ] < 2 2040 and 
0 < L < 2 2040 and len(S) < 2 2040 

1. n = \(len(X)/8)i B]. 

2. z = lcft_cncodc(/?). 

3. forz' = 0ton-l: 

z = z || Keccak[ 512]( substring^ i*B*8, (i+\)*B*8) || 1111, 512). 

4. z = z || right_encode(«) || right cncodc(L). 

5. newX= z. 

6. T= bytepad(encode_string(5) || encode_string(“ParallelHash”), 136). 

7. return Keccak[512](7 || newX || 00 , L). 
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Appendix B—Hashing into a Range (Informative) 


Hash functions with variable-length output like cSHAKE, KMAC, TupleHash, and ParallelHash 
can easily be used to generate an integer X within the range 0 <X< R, denoted as O.i?-1 in this 
document, for any R. The following method will produce outputs that are extremely close to a 
uniformly distribution over that range. 

In order to hash into an integer in the range 0..A-1, do the following: 

1. Let k= [ lg(7?) 1 + 128. 

2. Call the hash function with a requested length of at least k bits. Let the resulting bit string be 
Z. 

3. Let N = bits_to_integer(Z) mod R. 

N now contains an integer that is extremely close to being uniformly distributed in the range 
0.J?—1. For any t such that 0 < t < R, the following statement is true. 

Prob(0 - HR < 2~ m . 

This technique can be applied to SHAKE, cSHAKE, KMAC, TupleHash, or ParallelHash 
whenever an integer within a specific range is needed, so long as it is acceptable for the resulting 
integer to have this very small deviation from the uniform distribution on the integers {0, 1,..., 
A-l}. 


This technique depends on a method to convert a bit string to an integer, called bits_to_integer() 
above. 

bits_to_integer (bi, bi,..., bn): 

1. Let (bi, bi,bn) be the bits of a bit string from the most significant to the least significant 
bits. 


n 

2 . x=Y?"~% 

i\ 

3. Return (x). 
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